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ABSTRACT 


Shipboard  Naval  Automated  Data  Processing  (SNAP)  is  the  U.S.  Navy’s 
administrative  manager  for  surface  ships.  The  Department  of  the  Navy  is  developing  a 
replacement  system,  Naval  Tactical  Command  Support  System  Administrative  Module 
(NTCSSAM),  that  will  upgrade  the  software  and  hardware  to  be  more  consistent  with  the 
needs  of  the  Navy  in  the  21st  century.  NTCSSAM  is  not  being  developed  with  modem 
design  techniques  that  can  reduce  the  amount  of  time  required  to  develop  a  system.  This 
thesis  will  improve  the  development  of  NTCSSAM  and  produce  a  prototype  representing 
a  subset  of  its  functionality. 

We  review  and  analyze  QFD  and  the  Mayhew  design  methodologies  and  select  the 
QFD  tools  and  Mayhew  phases  to  improve  NTCSSAM.  In  addition  to  this,  a  survey  form 
is  used  to  compile  user  inputs  to  document  improvements  to  NTCSSAM.  To  improve 
NTCSSAM  we  construct  a  prototype  that  includes  functionalities  necessary  to  create  an 
enlisted  evaluation.  This  prototype  represents  a  subset  of  the  functionalities  of  NTCSSAM. 
The  prototype  includes  the  functionality  to  enter  crew  members,  enter  command 
information,  and  edit  text  for  creating  enlisted  evaluations. 

The  methodology  and  design  tools  improved  documentation  by  including  all 
design  inputs  on  matrices  making  them  accessible  to  users,  programers,  and  developers.  It 
reduced  the  amount  of  time  required  to  design  and  program  functionalities  for  NTCSSAM 
by  three  weeks.  The  survey  form  produced  a  comprehensive  list  of  functionalities  and 
provided  valuable  user  input  about  improving  NTCSSAM.  Using  these  methods  to  create 
a  prototype  for  NTCSSAM  improved  the  prototype’s  graphical  user  interface  of  the 
prototype  by  including  user  inputs. 
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I.  INTRODUCTION 


The  purpose  of  this  thesis  is  to  evaluate  which  methodologies  to  use  for  designing 
constructing  and  an  administrative  program  for  U.S  Navy  surface  ships.  Naval  Tactical 
Command  Support  System  Administrative  Module  (NTCSSAM)  is  a  administrative 
shipboard  program  that  is  under  development  at  NAVMASSO  and  intended  to  reduce  the 
administrative  burdens  found  on  naval  ships.  This  research  will  review  design  methods  and 
the  design  tools  that  can  be  used  in  order  to  construct  NTCSSAM.  As  an  example  of  one 
of  the  design  tools,  a  survey  will  be  conducted  of  fleet  personnel  where  they  will  indicate 
their  preferences  regarding  various  aspects  of  shipboard  administrative  management.  The 
last  section  of  the  research  will  explain  the  development  of  an  Enlisted  Evaluation  Program 
that  prints  evaluation  reports  for  United  States  Navy  enlisted  personnel. 

The  possible  methodologies  that  could  be  used  in  the  development  of  NTCSSAM 
will  be  analyzed  and  how  these  methodologies  improve  design.  The  importance  of 
analyzing  these  design  methods  is  to  demonstrate  how  these  methods  can  improve  the 
required  functionalities,  improve  the  interface,  and  maintain  an  acceptable  cost  level  of 
NTCSSAM  to  accomplish  administrative  tasks.  This  research  reveals  that  using  these 
proven  methodologies  and  their  tools  of  development  on  a  project,  such  as  NTCSSAM,+ 
can  significantly  improved  the  final  project.  These  design  tools  allow  the  users  and 
designers  to  establish  the  scope  of  the  functionalities,  improve  documentation,  and  reduce 
the  amount  of  time  spent  redesigning  a  product  when  conflicts  arise  in  the  design  process. 

NTCSSAM  is  designed  to  completely  consolidate  and  automate  all  shipboard 
administrative  requirements  and  significantly  reduce  the  manual  administrative  work  load 
of  fleet  personnel.  The  initial  design  phases  of  NTCSSAM  is  critical  to  a  successful  and 
functional  product  to  reduce  the  fleets  administrative  burden.  As  a  result,  a  review  of 
several  design  methods  and  their  benefits  will  be  provided  that  could  improve  the  initial 
development  of  NTCSSAM.  In  addition  to  the  methodologies  of  design  a  interview  will  be 
conducted.  This  interview  is  intended  to  solicit  user  preferences  and  desired  functionality 
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,0  be  deluded  in  NTCSSAM.  As  an  example  of  the  type  of  functionality  that  can  be 
included  in  NTCSSAM,  a  prototype  for  an  Enlisted  Evaluation  program  wdl  be  developed. 
This  pmgram  will  also  incorporate  several  of  the  design  methodologies  recommended  for 

the  design  of  NTCSSAM. 


A.  BACKGROUND 

The  amount  of  time  shipboard  personnel  devote  to  the  organization  and 
dissemination  of  administrative  information  consumes  an  average  56  man  hours  per  week 
updating  training  records  alone  IRef.  1].  Redueing  this  time  through  automation  would 
enable  personnel  to  spend  more  time  with  other  duties.  Shipboard  Naval  Automated  Data 
Processing  (SNAP)  system  is  the  current  shipboard  automated  system  intended  to  assist  in 
the  administrative  duties  onboard  naval  ships.  SNAP  attempted  to  alleviate  the  burden  o 
these  administrative  duties  and  was  successful  in  several  ways  but  not  complete. 

The  need  for  automating  all  the  administrative  facets  of  shipboard  management  an 
iu  advantages  has  been  written  about  for  many  yearn.  The^  needs  center  around  saving 
rtae  and  manpower  and  are  discussed  in  detail  in  [Ref.  1]  and  [Ref.  2,.  Functional 
improvements  to  SNAP  have  been  r^earched  and  several  are  described  m  [Ref.  1]^ 
NTCSSAM  is  intended  to  automate  all  faces  of  shipboard  administrative  requirements  an 
be  a  networked  administrative  manager  that  performs  all  the  functional  lequimments 
needed  in  shipboard  administration.  NTCSSAM  will  also  interact  with  or  contain  the 


functionality  of  the  programs  listed  in  Figure  1  on  page  3. 

NTCSSAM  is  designed  to  combine  all  these  administrative  requirements  under  one 

system  to  provide  administrative  documentation  for  shipboard  inspections  as  well  as  the 
frequent  administrative  mpotting  to  off  ship  type  commanders,  supply  departments,  an 
personnel  requirements.  Incorporating  all  the  functions  and  data  included  in  Figure  1  on 
page  3  and  other  shipboard  administrative  requirements  under  NTCSSAM  will  mduce  the 
redundancy  of  data  and  the  amount  of  time  personnel  spend  colieetmg  information, 
maintaining  records,  preparing  reporis,  and  disseminating  information  to  vanous  channels. 
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B.  OBJECTIVES 

This  research  will  cover  three  different  aspects  related  to  NTCSSAM.  The  first 
aspect  will  be  to  prioritize  the  areas  of  administrative  requirements  listed  on  the  survey 
form  in  Figure  2  on  page  7.  This  prioritizing  will  represent  the  top  four  areas  that  the 


Source  Data  System  (SDS) 

Uniform  Military  Disbursing  System  (UMIDS) 

Source  Data  System  (SDS)  /r.*r»TT'.c\ 

Real-Time  automated  Personnel  Identification  System  (RAPIDS) 

Naval  Aviation  Logistics  Command  Information  System  (NALCOMIS) 
Total  Force  Manpower  Management  System  (TFMMS) 

SNAP  Automated  Medical  System  (SAMS) 

Dental/Medical  Information  System  (DENMIS) 

Enlisted  Distribution  and  Verification  Report  (EDVR) 

Maintenance  Resource  Management  System  (MRMS) 

Onboard  Proficiently  Maintenance  Integration  System  (OPMIS) 


Figure  1:  Proposed  Functions/Data  to  be  Included  in  NTCSSAM 


interviewed  users  would  like  to  see  automated  in  NTCSSAM.  In  addition  users  will 
indicate  any  specific  functional  description  that  they  would  like  to  see  included  in 
NTCSSAM.  Second,  aspects  of  several  design  methodologies  will  be  reviewed  to  assist  in 
organizing  the  functionalities  required  by  the  user.  These  design  methods  are  the  kind  of 
design  techniques  that  can  to  used  in  the  development  of  NTCSSAM.  These  advanced 
design  methodologies  are  recommended  to  establish  a  compatible  interaciton  between 
users,  designers,  and  developers.  These  tools  or  methods  of  design  enhances  the 
documentation  of  a  project  and  several  have  been  proven  highly  successful  in  modem 
commercial  industry. 

These  methods  of  design  enhance  the  relationship  between  users,  designers,  and 
engineers  ensuring  the  highest  quality  product  and  can  be  used  on  projects  of  varying  size. 
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The  final  area  of  research  involves  the  development  of  a  smaller  project  using  several  of 
the  design  methods  that  will  be  discussed.  This  Thesis  will  introduce  a  working  prototype 
of  a  Windows  based  Enlisted  Evaluation  Program  that  can  be  implemented  into 
NTCSSAM.  This  includes  basic  design  requirements,  user  input,  development  of  a 
prototype,  and  user  inputs  about  the  prototype.  This  will  provide  specific  information 
regarding  a  human  factors  analysis,  what  users  like  about  the  screens  and  functionality,  of 
a  Windows  based  Enlisted  Evaluation  Program.  The  software  interface  design  of  the 
Enlisted  Evaluation  Program  is  presented  as  an  example  of  a  project  that  has  the  potential 
to  reduce  the  administrative  requirements  for  naval  personnel  and  how  it  can  be  emulated 
directly  by  the  Navy  and  the  administrative  functions  to  be  incorporated  in  NTCSSAM. 
Using  the  Enlisted  Evaluation  Program  as  an  example,  the  documented  user  preferences 
can  be  incorporated  into  a  networked  Windows  based  prototype  for  NTCSSAM. 


C.  INTERFACE  DESIGN  REQUIREMENTS 

The  presentation  of  data  is  one  of  the  most  important  considerations  when 
developing  a  system  that  manipulates  information  and  data  into  the  desired  formats  to  be 
displayed,  reviewed,  or  printed.  Shipboard  Naval  Automated  Data  Processing  (SNAP) 
features  a  layered  menu  approach  where  information  can  be  found  by  selecting  from  one 
choice  on  a  screen  cascading  down  to  the  layer  that  will  display  your  information.  To  exit 
retracing  your  path  is  sometimes  the  only  way  to  return  to  the  main  menu.  A  detailed 
discussion  of  the  drawbacks  and  benefits  of  this  system  are  presented  in  [Ref.  1]  but  it 
required  more  time  and  effort  for  the  user  who  often  had  to  memorize  the  path  to  find  the 
functional  screen  they  were  looking  for.  Today  the  industry  standard  of  windows  based 
applications  is  so  dominant  that  attempting  to  emulate  any  other  style  of  interface  would 
increase  the  initial  time  required  to  learn  an  application  unnecessarily.  One  hundred  percent 
of  all  interviews  conducted  with  the  survey  form  found  in  Figure  2  on  page  7  indicated  a 
familiarity  with  windows  based  applications  and  the  use  of  pull  down  menus,  further 
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supporting  the  use  of  the  Windows  standard.  The  development  of  NTCSSAM  interface 
requirements  is  best  represented  following  the  standards  set  forth  in  a  Windows  based  applications 
and  is  required  to  follow  the  standards  as  described  in[Ref.  3],  the  government  standards  for 
emulating  Windows  environments. 

D.  DESIGNING  A  GRAPHICAL  USER  INTERFACE 

Developing  a  graphical  user  interface  consists  of  numerous  facets  but  most  of  these  relate 
to  cost,  ease  of  use,  and  functionality.  It  is  not  a  simple  task  to  require  a  product  to  perform  exactly 
to  the  specifications,  reduce  the  cost  while  making  the  product  so  intuitive  and  easy  to  use  little  or 
no  training  is  required.  In  order  to  achieve  these  goals  or  even  come  remotely  close,  there  is  a  path 
or  course  of  action  that  must  be  taken  to  ensure  that  the  desired  results  of  minimal  costs,  ease  of 
use  and  a  fully  functional  product  are  achieved[Ref.  4].  The  specific  guidelines  of  constructing  a 
product  may  depend  on  its  size  and  use,  but  many  corporations  are  not  inventing  new  methods  of 
how  to  approach  design  rather  they  are  seeking  the  expertise  of  others  or  using  a  method  proven 
in  other  corporations  that  have  used  a  specific  design  method  to  improve  or  make  a  new  product 

better  [Ref  5]. 

In  the  design  of  a  graphical  user  interface  there  is  always  a  trade  off  between  cost,  ease  of 
use,  and  functionality.  User  interface  design  is  a  matter  of  compromise  for  powerful  functionality 
with  a  simple  clear  interface.  Users  demand  ease  of  use  and  ease  of  learning  always  at  a  minimal 
cost.  When  you  design  a  interface  conflicts  between  funtionality,  ease  of  use,  and  cost  always 
arise.  These  conflicts  between  designers,  manufactures,  and  consumers  are  better  solved  when  the 
use  of  some  type  of  structured  method  or  technique  is  used  to  assist  in  organizing  and  making  the 
necessary  trade-offs  that  inevitably  arise.  Not  finding  these  conflicts  before  a  certain  stage  and 
certainly  before  coding  begins  will  result  in  one  of  the  three  facets  mentioned  above  not  meeting 
with  the  standards  expected  by  the  consumer.  A  structured  method  of  design  promotes  good 
design  discussions  for  a  specific  product  and  its  users  and  allows  for  a  well  documented  product. 

NTCSSAM  is  no  different  than  any  other  product  when  it  comes  to  the  philosophy  of 
design  and  a  quality  product  for  it  users.  NTCSSAM  should  be  developed  following  a  method  or 
technique  that  has  been  used  and  proven  in  commercial  industry  to  ensure  it  will  meet  the  basic 
facets  of  design  mentioned  above.  Choosing  a  specific  method  and  justifying  it  is  not  a  simple 
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task.  Because  of  this,  a  detailed  comparison  of  design  methods  will  not  be  given.  Rather  a 
review  of  some  of  the  techniques  is  better  served.  Of  the  several  design  methods  reviewed; 

•  Design  methods  by  Mayhew 

•  Developing  user  interfaces  by  Hartson  and  Hix 

•  QFD  by  Bob  King 

QFD  offers  the  most  detailed  and  documented  method  that  is  most  suitable  for  the 
dynamic  personnel  structure  in  the  Navy.  This  documentation  is  supported  through  the  use 
of  several  tools  for  obtaining,  organizing,  and  coordinating  information  that  must  be 
applied  to  the  design  of  a  project.  The  effectiveness  of  QFD  or  managing  information  has 
also  been  demonstrated  by  several  corporations  including  users  form  major  U.S.  and 
Japanese  corporations  [Ref.  6].  In  addition  to  QFD  the  methodology  of  Mayhew  provides 
a  good  structure  for  the  overall  design  of  a  product  dividing  the  project  into  five  phases  of 
design  where  specific  tasks  are  divided  among  various  organizations. 

E.  OUTLINE 

This  research  presents  major  topics  at  each  chapter.  The  major  focus  of  this  thesis 
is  centered  around  three  areas.  The  first  is  to  present  different  types  of  design 
methodologies  and  the  tools  they  use  to  improve  the  design  and  development  of  NTCSS. 
The  second,  reviews  the  needs  of  the  users  through  a  survey  form  found  in  Figure  2  on  page 
7  and  include  a  list  of  desired  functionality  from  the  users  from  this  survey  as  depicted  in 
Figure  3  on  page  8.  The  last  aspect  of  this  thesis  will  discuss  the  construction  of  an  Enlisted 
Evaluation  Program  whose  functionality  can  be  incorporated  into  NTCSS.  A  prototype  of 
this  Enlisted  Evaluation  Program  is  developed  to  illustrate  the  functionality  desired  by 
users  and  illustrate  the  enlisted  evaluation  program  and  its  development  using  the  tools  of 
the  design  methods  discussed. 
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Automating  Navy  Administrative  Requirements 

Date: _ 

Name: _ 

Positions  held: _ 

The  goal  of  this  survey  is  to  improve  the  functionality  of  SNAP  by  having  the  users 
critique  the  functionality  of  the  system. 

The  use  of  current  technology  can  improve  SNAP  so  that  it  will  manage  all  shipboard 
administrative  data  and  produce  required  reports  without  all  the  traditional  work.  To  this 
end,  it  is  imperative  to  have  the  user  define  what  a  system  is  to  do.  Envision  any  repetitive 
reports  that  your  chain  of  command  wanted  that  left  you  scrambling  through  service 
records  or  old  SNAP  files.  If  all  this  information  were  available  from  a  workstation,  report 
writing  would  be  much  simpler. 

Listed  below  are  areas  of  SNAP  that  could  benefit  by  improving  their  functionality. 
Rank  the  4  areas  where  you  think  improvement  is  most  required.  List  any  functionai 
tasks  that  you  would  like  to  see  changed  or  included.  An  example  of  a  functional  task 
is;  “I  would  like  to  be  able  to  print  out  a  13  week  graph  of  someone’s  PQS  progress  for 
their  PQS  tasking”. 

Maint  Tickler 

Berthing  Lifeboat 

Personnel  (evals  /edvr/lortarp) 
control 

1. _ 

2. _ 

3.  _ 

4.  _ 

3.  Are  you  familiar  with  Windows  based  applications  i.e.  the  use  of  pull  down  menus  and 
toolbars? 

(circle  one)  yes  no 

4.  What  types  of  software  programs  have  you  used  that  were  designed  to  manage  adminis¬ 
trative  functions.  What  did  you  like  most  or  dislike  most  about  these  programs.? 

5.  Please  give  any  other  comments  about  administrative  management. 

Figure  2:  Survey  Form  for  NTCSSAM 


Custom  Query  system  Watch  Bill 

Training/PQS/Schools  Dep/Div 

Career  Counselor/ Advancement  Visitor 

TASKS 
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Department  division 

professional  development  boards 
training  exercises  and  selex  completion  and  tracking 
departmental  tickler,  project  planner 
material  history  logs 

Training  and  PQS 

who’s  prd  is  within  six  months 

list  crew  not  qualified  in  given  pqs  like  general  dc 

track  pqs  for  individual  school 

start  date,  estimated  completion  date,%  complete 
create  13  week  tracking  for  crew  individual 
track  proficiency  watches  necessary  for  maintaining 
qualification 

list  nec’s  and  crew  on  board  that  fill  them  filter  by 
division  and  department 
pqs  qualifiers  list 
schools 

list  who  needs  to  go  based  on  watches 
list  who  is  leaving  in  6  months  and  recommend 
a  replacement 
availability  list 

schools  scheduled  with  prospective  crew 
members  for  attendance 
support  for  gmt,  departments  divisional  training 
yearly,  quarterly,  monthly  and  if  required 
weekly  training  plan 

Watch  Bill 

create  a  fire  fighting  and  import  watch  bill  that  don’t  conflict 
create  under  way  watch  bill  by  checking  against  PQS 
enter  crew  into  watch  bill  then  have  query  fill 
remaining  slots 
change  section  of  person 
enter  new  qualifications  and  schools 
print  crew  member  with  qualifications  and  schools 
list  people  by  section  with  watch  standing 
who  has  been  to  FF  team  trainer  and  what%  of  the 
team  did  it  together 


Figure  3:  Desired  Functionality  For  NTCSSAM 
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Division  Officer  notebook/  personnel 

advancement  eligibility 

what  requirements  need  to  be  met  pars,  courses, 
leadership  exam 

list  where  every  one  lives  by  compartment  and  list  rack 
number 

who  is  eligible  for  mess  duty 
prospective  gain  and  losses 

generate  messages  for  various  requirements  like  prospective 
gain  and  losses 
recall  bill 
ships  bills 

Supply 

List  all  jobs  with  casrep  parts  and  their  status 

lis  by  work  center,  department,  all  or  JSN 
Write  CASREP  message 
Lifeboat 

Life  boat  alpha  list 
lifeboat  muster  list 
lifeboat 
Visitor  control 

access  security  list 

automatic  addition  and  deletion  to  master  list  on  quarter  deck 
list  by  name  or  organization 

Berthing 

list  all  empty  racks 

list  racks  in  a  compartment  with  who  is  in  them  which  are 
empty 

query  name  and  indicate  rack  number 

Career  counselor 

Advancement  eligibility 

muster  list,  order  exams 

Ships  office 

mailing  labels 
social  roster 


Desired  Functionality  For  NTCSSAM  Continued 
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II.  NTCSSAM  FUNCTIONAL  DEVELOPMANT 


Naval  Tactical  Command  Support  System  (NTCSSAM)  is  the  next  phase  in  the 
development  of  a  total  shipboard  automated  management  tool  that  includes  maintenance, 
supply  and  administrative  requirements  for  ship  and  soar  Naval  personnel.  NTCSSAM  is 
the  new  name  of  the  system  that  is  currently  called  SNAP,  Shipboard  Naval  Automated 
Data  Processing  system,  and  whose  most  recent  version  is  called  SNAP  in.  The  first  steps 
being  take  in  the  development  of  NTCSSAM  is  to  review  and  automate  the  Administrative 
module  of  SNAP  and  include  more  advanced  functionality  into  NTCSSAM.  NTCSSAM 
administrative  module  is  designed  to  reduce  and  automate  the  manual  administrative  work 
load  both  ashore  and  afloat.  In  addition  to  the  improvements  to  the  graphical  user  interface 
and  functionality  of  SNAP,  improvements  will  be  made  in  updating  software  and  hardware 
and  bringing  them  more  in-line  with  today’s  standards.  The  Hardware  and  software 
concerns  will  not  be  discussed  instead  a  concentration  on  improving  the  functionality  of 
NTCSSAM  and  using  an  advanced  design  tool  or  methodology  for  construction 
NTCSSAM  will  be  discussed 

A.  DESIGN  METHOD 

User  interface  design  is  an  exercise  in  documentation  and  the  coordination  of  the 
users  desires.  It  involves  trade-offs  between  powerful  functionality  and  a  simple  and 
intuitive  common  sense  interface.  An  interface  should  be  easy  to  use  and  learn  and  have  a 
consistent  design  across  the  interface.  In  addition  to  this  performance,  cost  must  be  factored 
into  design  to  meet  the  requirements  of  the  consumer.  Because  these  requirements  conflict 
with  each  other  and  are  present  throughout  the  entire  design  of  a  product  a  method  or 
technique  is  required  to  guide  and  help  effectively  manage  the  design  of  the  user  interface 
and  the  functionality  it  will  posses.  A  good  method  or  technique  will  assist  in  making  good 
design  decisions  ensuring  all  aspects  of  design  are  meticulously  compared  and  reviewed. 
The  types  of  design  methods  that  will  be  discussed  all  emphasize  a  structure  and 
consistency  in  each  method.  Each  recommends  that  tasks  for  a  design  method  be  carried 
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out  in  a  particular  order  at  certain  points  over  the  entire  life-cycle  of  the  design  project  and 
software  development  while  recognizing  some  may  be  conducted  in  parallel. 

The  design  methods  that  are  describe  are  a  representation  of  the  type  of  structure 
that  can  be  used  in  the  construction  of  a  new  product  or  upgrading  a  product  using  an 
interface  design  tool  or  method.  These  methods  are  complex  and  require  extensive 
discussion  for  their  implementation.  The  description  of  these  methods  is  to  give  the  reader 
some  idea  of  the  style  and  structure  that  is  used  and  not  a  detailed  analysis  of  its 
implementation.  The  details  of  these  design  methods  can  be  found  in  the  references  for  each 
respective  one. 

1.  Mayhew  Design 

The  design  method  describe  by  Deborah  Mayhew  consists  of  five  phases  listed  in 
Figure  4.  The  life-cycle  depicted  by  Mayhew  is  divided  up  into  tasks  delineated  to  specific 

1:  Scoping 

2:  Functional  Specification 
3:  Design 
4:  Development 

Figure  4:  Mayhew  Phases  of  Design 

departments  within  an  organization.  All  tasks  (that  is,  not  just  user  interface  tasks)  in  a 
typical  system  development  life  cycle  are  presented  in  the  order  that  they  would  be  carried 
out,  according  to  the  responsible  organization  [Ref.  4].  Mayhew’s  phases  are  best  described 
with  a  graphical  representation  where  interface  tasks,  project  team  responsibility,  and 
interface  tasks  are  listed  as  shown  in  Figure  5  on  page  13.  This  figure  is  the  graphical 
representation  of  the  second  phase  of  Mayhew’s  design,  the  Functional  Specification 
phase.  User  interface  tasks  are  written  in  shaded  boxes  on  the  graph.  The  clear  or  white 
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boxes  represent  actions  required  of  the  project  team.  Moving  from  left  to  right  represents 
the  relative  time  for  each  event.  The  layout  of  the  phases  in  a  specific  order  gives  the 
impression  that  tasks  are  completed  in  a  distinct  order  with  the  beginning  of  one  relying  on 
the  completion  of  another.  This  is  not  always  the  case.  Several  of  the  tasks  can  overlap  and 
can  be  conducted  at  the  same  time.  For  one  thing,  the  different  groups  will  have  their  own 
tasks  to  be  working  on.  Referring  back  to  Figure  5,  the  project  team  can  be  working  on  the 
functional  specification  task  while  the  user  interface  group  can  be  working  on  the  task 
analysis.  However,  the  user  interface  group  must  complete  task  analysis  before  beginning 
with  user  interface  goal  setting. 


Functional  Specification  Phase 


Adding  Human  Factors  to 
The  Software  Development  Process 


Application 
Project  Team 


Functional 

Specification 


Training  and 
Documentation 
Definition 


User 

Interface 

Group 


Analysis  [ 


Goal  Setting 


Figure  5:  Mayhew’s  Functional  Phase  from  [Ref.  4] 


2.  QFD 

Quality  Function  Deployment  (QFD)  is  a  design  technique  for  integrating  customer 
requirements  into  product  design.  QFD  was  introduced  into  the  United  States  by  Yoji  Akao 
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in  October  of  1983  in  the  journal  of  the  American  Society  of  Quality  Control.  Since  then 
major  corporations  such  as  General  Electric  and  Ford  Motor  Corporation  have  used  QFD 
to  better  implement  consumer  demands  and  bridge  the  gap  between  manufacturing  and 
design  using  this  method  of  development.  QFD  has  proven  to  be  excellent  at  integration 
new  technology,  managing  and  organizing  the  functionality  of  products  and  their  cost.  The 
main  goal  of  QFD  is  to  expand  the  time  it  takes  to  define  the  product  but  shorten  the  time 
it  takes  to  make  changes  or  redesign  the  product  after  constmction.  The  result  is  intended 
to  eliminate  extensive  redesign  that  costs  more  and  takes  more  time  than  the  time  spent  on 
the  initial  design  phase.  This  design  process  can  be  represented  by  the  drawing  found  in 
Figure  6.  The  defining  of  the  product  takes  longer  but  the  time  saved  in  redesign  results  in 


Figure  6;  Old  Design  Method  and  QFD  Design  System  from  [Ref.  5] 


a  net  reduction  in  total  product  design.  The  time  savings  from  using  QFD  can  be  one  third 
to  as  much  as  one  half  the  time  that  it  would  take  using  conventional  methods  [Ref.  5].  QFD 
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can  be  organized  into  four  phases  of  planing  where  the  seven  tools  of  QFD  are  utilized  to 
enhance  the  process.  Using  the  seven  tools  of  QFD,  a  quality  matrix  is  constmcted.  It  is  this 
matrix  of  QFD  which  maintains  the  detailed  documentation  and  acts  as  the  support  to 
bridge  the  gaps  between  design  and  manufacturing  ensuing  a  quality  product  for  the  user 
and  preventing  extensive  redesign. 

a.  Four  Phases  of  QFD 

QFD  is  a  design  process  that  centers  on  the  needs  of  the  consumer  or  user. 
It  is  designed  to  focus  on  these  needs  and  translate  them  into  technical  specifications  and 
ultimately  a  product.  The  QFD  process  usually  occurs  in  four  phases  as  depicted  in  Figure 
7.  The  first  phase  of  QFD  is  “Customer  Demands”  or  “Voice  of  the  Consumer.”  This 


1:  Customer 
Demands 


2;  Basic  Design  Requirements 


PHASE  I 


4:  Part  Characteristics 


3:  Key  Design 
Requirements 


J 


PHASE  n 


6:  Process  Operations 


5:  Key  Part 
Characteristics 


J 


PHASE  ni 


8:  Production  Control! 
Requirements 


7:  Key  Process 
Operations 


J 


PHASE  IV 


Figure  7:  Four  Phases  of  QFD  from  [Ref.  6] 


represents  the  desires  of  the  consumer  or  user  and  what  they  would  like  the  product  to  do. 
This  involves  finding  both  the  requirements  the  user  knows  about  and  the  latent  demands 
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of  the  user  before  any  other  step  is  taken.  The  users  demands  or  requirements  involves  the 
design  team  having  frequent  discussions  with  current  and  potential  users  of  the  system. 
Determining  the  needs  of  the  user  are  extremely  necessary  but  are  no  means  adequate  in 
determining  the  scope  of  the  products  functionality.  Integrating  senior  management  and 
policy  makers  to  determine  the  direction  in  which  requirements  are  heading  and  if  any  new 
requirements  will  be  required  that  current  users  are  not  aware  of  must  be  integrated  into  the 
products  functionality.  Phases  n  through  Phase  IV  of  the  QFD  Cycle  rely  heavily  on  the 
information  gathered  in  Phase  I.  The  remaining  phases  relate  to  parts,  manufacturing,  and 
the  control  requirements  of  manufacturing.  In  Phase  11  the  key  technical  characteristics  are 
translated  into  part  characteristics.  In  Phase  HI  of  the  QFD  cycle,  the  key  part 
characteristics  are  linked  to  key  manufacturing  operations.  And  in  Phase  IV  the  key 
manufacturing  operations  are  assigned  specific  control  requirements  to  insure  reliability 
and  consistent  quality  [Ref.  7]. 

b.  Seven  Tools  of  QFD 

There  are  seven  planning  tools  that  are  used  during  the  four  phases  of  QFD. 
The  tools  are  listed  in  Figure  8  on  page  17  with  a  brief  description  of  each.  All  of  the  tools 
are  used  for  organizing  and  planning  information  necessary  for  design.  These  tools  are 
different  than  other  tools  used  in  development  because  they  are  simple  to  understand  and 
use  [Ref.  5].  Because  they  are  so  simple  more  people  and  organizations  want  to  use  them. 

c.  QFD  Matrix  Charts 

QFD  is  designed  to  support  up  to  thirty  matrices  to  organize  the  data  that  is 
collected  throughout  the  design  process.  The  purpose  of  these  matrices  is  to  allow  designers 
and  manufactures  to  work  from  the  same  set  of  requirements  and  information  while 
developing  each  product.  Each  one  of  the  matrices  compare  two  elements  of  design  and 
graphically  represent  the  relationship  one  has  with  the  other.  Two  such  areas  may  be 
customer  demands  and  quality  characteristics.  As  an  example  we  will  discuss  the  first 
matrices  that  is  normally  developed  and  what  tools  are  used  to  create  the  matrices.  The  first 
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step  after  collecting  information  from  the  consumer  or  user  is  to  group  his  desires  using  an 
affinity  diagram  (also  called  a  KJ  Diagram).  The  affinity  diagram  organizes  the  users  ideas 
into  groups  that  will  be  placed  into  a  column  in  the  matrix.  From  each  of  the  elements  in 
the  Affinity  Diagram  a  list  of  Quality  Elements  must  be  listed  for  each  one.  These  two 
elements,  the  demands  of  the  consumer  and  the  quality  elements,  are  then  entered  into  a 
matrices.  The  user  inputs  are  located  along  the  left  hand  side  of  the  matrix  and  the  quality 
elements  are  placed  on  the  top  of  the  matrix.  This  not  only  lists  all  the  demands  of  the  user 
but  allows  the  comparison  of  these  desire  to  be  evaluated  with  regard  to  a  quality  element. 

1 :  Affinity  Diagram  -  organizes  customer  demands 
2:  Interrelationship  Diagram-  which  ideas  influence  another  idea 
3:  Tree  Diagram  -  Identifies  ideas  in  greater  and  greater  detail 
4:  Matrix  Chart  -  Compares  ideas  for  correlations 
5:  Matrix  Data  Analysis  Chart  -  What  markets  to  enter 
6:  Process  Decision  Program  Chart  -  Lists  what  can  go  wrong 
7:  Arrow  Diagram  -  Shows  aspects  that  can  be  completed 
simultaneously 


Figure  8:  Seven  Tools  of  QFD 


B.  QFD  AND  A  SPECIFIC  DESIGN  METHOD 

The  development  of  NTCSSAM  will  include  communicating  fleet  and  type 
commanders  requirements  to  analysts  and  programmers  that  adequately  describe  the 
desired  functionality  of  the  new  system.  In  addition  to  the  requirements  set  forth  at  these 
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levels  fleet  personnel,  or  users,  will  evaluate  the  graphical  interfaces  for  NTCSSAM  while 
they  are  being  developed  to  ensure  that  the  implementation  of  aU  functionalities  is  included 
and  the  quality  of  the  end  product  meets  the  expectations  of  the  users  in  the  fleet.  To  act  as 
a  nucleus  of  users  NAVMASSO  has  created  a  Fleet  Design  Team  from  senior  enlisted 
personnel  from  various  commands  and  warfare  specialties  to  act  as  the  embodiment  of  the 
users  in  the  fleet  that  will  use  NTCSSAM.  This  Fleet  Design  team  will  rely  on  their  own 
expertise  of  SNAP  and  provide  the  necessary  inputs  to  analysts  and  programmers  to  ensure 
a  quality  product  is  developed. 

1.  Initial  Development 

The  process  of  developing  an  interface  with  the  desired  functionality  can  seem 
rather  simple.  The  Fleet  Design  Team  interviews  the  fleet  and  describes  what 
administrative  requirements  the  fleet  desires  to  designers.  Programmers  and  designers  then 
convey  with  each  other  and  construct  the  program.  After  the  constmction  of  the  program 
the  Fleet  Design  Team  evaluates  the  product  for  its  ease  of  use  and  functionality  ensuring 
it  meets  the  specifications  they  desire.  Are  expert  uses  the  best  choice  for  a  team  of 
interviewers?  Expert  users  may  know  the  system  but  are  not  trained  to  interview  people  and 
may  not  necessarily  know  the  technology  that  can  influence  the  way  questions  should  be 
asked  [Ref.  5].  For  example,  does  the  fleet  design  team  know  how  to  derive  the  latent  needs 
of  the  user  from  an  interview?  Does  the  Fleet  Design  Team  know  the  spectrum  of  users  that 
require  being  interviewed?  Are  the  survey  forms  and  interview  techniques  consistent  so 
conflicts  in  functionality  can  easily  be  resolved.  All  these  questions  should  be  reviewed  in 
detail  before  customers  or  fleet  members  are  interviewed  to  obtain  information.  There  must 
be  a  methodology  to  translate  customer  needs  into  a  product  and  organize  multiple 
departments  of  designers  and  engineers  to  efficiently  accomplish  this. 

2.  Improving  NTCSSAM  Though  Design 

The  design  methods  listed  above  have  been  proven  in  the  commercial  world.  They 
show  that  a  structured  design  not  only  improves  the  product  but  reduces  the  amount  of  time 
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to  produce  it  and  minimizes  the  redesign  process.  NTCSSAM  can  benefit  from  these 
methods  in  several  ways.  Using  trained  interviewers,  as  recommended  in  [Ref.  4],  one  can 
better  determine  the  users  requirements  while  determining  if  the  users  have  any  latent  needs 
which  are  not  conveyed  by  the  user.  Some  of  the  latent  requirements  of  the  user  may  be 
solved  by  the  new  technologies  to  be  implemented  in  NTCSSAM.  These  technologies  are 
familiar  to  trained  interviewers  where  expert  users  of  SNAP  or  the  Reet  Design  Team 
would  not.  A  structured  design  method  will  also  provide  NTCSSAM  with  a  more  organized 
means  of  documentation.  Several  fleet  personnel  interviewed  indicated  sending  messages 
concerning  the  improved  functionality  to  SNAP  n  over  a  year  ago  [Ref.  8].  These  inputs 
could  have  been  consolidated  and  used  in  a  survey  form  today  and  disseminated  to  fleet 
personnel,  most  of  the  administrative  needs  then  are  still  the  same  today.  In  addition  to  fleet 
input,  inspection  teams  have  requirements  that  they  are  developing  that  can  be  included  as 
functional  tasks.  These  functionalities  are  still  pertinent  even  though  users  are  unaware  of 
these  additions  today.  Obtaining  this  type  of  information  is  discussed  in  [Ref.  6]  where 
interviewing  senior  personnel  and  developmental  personnel  in  an  organization  can  reveal 
other  functionalities  not  found  form  the  users  requests. 

C.  NTCSSAM  SURVEY  FORM 

Surveys  are  one  of  the  most  common  and  intuitive  tools  to  solicit  large  audiences 
for  information  regarding  their  demands  for  a  system  they  wish  developed.  Surveys  can  be 
used  to  compile  information  or  to  compare  various  products  to  determine  a  certain  level  of 
quality.  Surveys  are  a  good  way  to  collect  information  but  they  have  their  limitations  like 
anything  else.  Users  will  not  tell  you  everything  about  a  product  or  have  a  limited  view  of 
possibilities  for  a  product  based  on  their  limited  exposure  or  knowledge  of  technological 
improvements.  Revealing  the  customers  needs  or  opinions  is  the  purpose  for  generating  a 
survey.  The  survey  generated  for  NTCSSAM  is  intended  to  consolidate  the  customers  need 
rather  than  their  opinion  of  a  product. 
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1.  Customer  Needs 

Customer  demands  can  be  divided  into  three  areas;  what  customers  expect  but  not 
tell  you  about,  what  they  tell  you  they  want  and  what  they  need  but  have  not  considered. 
This  division  of  needs  has  been  researched  by  Professor  Kano  in  Japan  where  he  developed 
a  chart,  Figure  9,  to  display  these  characteristics.  The  top  arrow  represents  “exciting 


Figure  9:  Customer  Needs  from  [Ref.  9] 


quality”  that  producers  and  developers  know  the  users  need  or  will  end  up  using  in  the 
future.  The  middle  arrow  represents  “one-dimensional  quality”  where  customers  tell  you 
what  they  want.  The  bottom  arrow  represents  items  that  are  expected.  The  expected  aspects 
or  functions  are  less  likely,  if  at  all,  to  be  conveyed  by  the  consumer  to  the  survey  or 
interviewer. 
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2.  Survey  Form  Results 

The  survey  form  that  is  shown  in  Figure  2  on  page  5  is  intended  to  provide 
NAVMASSO  with  user  inputs  regarding  desired  functionalities  to  be  included  into 
NTCSSAM.  Users  were  also  asked  to  prioritize  areas  that  they  would  like  to  see  improved 
by  listing  the  top  four  areas  they  would  like  to  see  worked  on  and  improved  to  become  part 
of  NTCSSAM.  The  survey  revealed  the  four  top  areas  in  the  order  of  highest  priority  first 
as; 

•  Training  and  PQS 

•  Watch  Bill 

•  Dept/Div 

•  Maintenance 

Each  of  these  were  listed  more  than  any  of  the  others  with  Training  and  PQS 
receiving  a  higher  priority  than  the  Watch  Bill.  All  of  the  surveys  indicated  each  user  being 
familiar  with  windows  based  applications.  Several  PC  based  software  programs  were  being 
used  in  the  fleet  to  assist  in  administrative  management  including  TAMP  for  PQS  and 
Training.  Users  also  revealed  they  are  familiar  with  a  DOS  based  evaluation  program  but 
did  not  indicate  the  name  and  contended  it  was  not  user  friendly.  Most  of  the  comments 
about  administrative  management  indicated  a  disbelief  that  a  SNAP  based  system  could 
fulfill  the  needs  of  the  fleet  and  recommended  third  party  products  that  could  be  used  on  a 
networked  group  of  PC’s.  Users  also  listed  a  number  of  functionalities  that  is  included  in 
Figure  3  on  page  9. 
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m.  CONSOLIDATED  LIST  OF  RELATED  RESEARCH 


A.  THESIS  RESEARCH  ON  TRAINING 

There  are  two  theses  that  have  researched  the  area  of  training  for  improving  and 
upgrading  SNAP.  The  first  simply  describes  what  the  training  requirements  are  for  ship 
board  personnel  as  placed  on  them  by  Type  commanders  in  their  respective  fleets  [Ref.  2]. 
[Ref.  2]  can  give  the  reader  a  consolidated  report  on  the  various  requirements  and  what  the 
reports  for  these  requirements  look  like  without  reading  the  large  volumes  published  by  the 
Navy  regarding  this  subject.  The  most  recent  research  has  been  done  by  Conrad  Chun  and 
William  Estrada  in  their  1992  Thesis  “SNAP-III  Training  Administrative  Subsystem 
Integrated  Functional  Description”  [Ref.  1].  This  thesis  provides  a  functional  description 
for  a  shipboard  training  administrative  subsystem  following  the  U.S.  Navy  Standard 
Organization  and  Regulations  Manual.  This  thesis  list  the  requirements  and  enhancements 
necessary  to  achieve  a  working  administrative  training  module. 

B.  ARGOS 

Argos  is  a  system  designed  to  facilitate  the  reduction  of  paperwork  onboard  Naval 
Ships.  The  attractive  part  of  ARGOS  is  its  use  of  a  user  friendly  graphical  user  interface 
created  with  the  software  HyperCard  on  an  Apple  Macintosh.  ARGOS  has  a  tightly  linked 
graphical  user  interface  with  an  underlying  data  structure.  ARGOS  is  being  developed  in 
several  modules  that  can  be  combined  and  used  for  administrative  requirements  on  Naval 
Ships.  One  of  the  major  goals  of  ARGOS  is  to  reduce  the  amount  of  time  required  to  learn 
a  system  and  make  it  easier  to  use. 

C.  WINOMMS 

Winomms  is  another  graphical  user  interface  designed  to  manage  maintenance 
requirements  on  Naval  Ships.  This  is  a  Windows  based  application  created  using 
Asymmetric’s  Toolbook.  Toolbook  is  designed  to  allow  rapid  prototyping  of  display 
screens  to  create  graphical  interfaces.  The  creation  of  Winomms  was  designed  to  lay  on  top 
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of  the  current  data  structures  found  in  SNAP  and  be  the  interface  users  interact  with  to 
obtain  data  and  produce  reports. 
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IV.  ENLISTED  EVALUATION  PROGRAM  OVERVIEW 

A.  ENVIRONMENT  OF  EVALUATION  PROGRAM 

1.  Evaluation  Program 

The  Enlisted  Evaluation  Program  is  a  Microsoft  Windows  application  developed 
with  Microsoft’s  relational  database  software  Access.  Access  conforms  to  the  government 
requirements  for  software  design  listed  in  [Ref.  3]  and  is  ideally  suited  for  developing  rapid 
prototypes.  This  rapid  prototype  tool  is  made  to  develope  graphical  user  interfaces  and 
combine  this  graphical  interface  with  an  underlying  relational  database. 

2.  Evaluation  Program  Environment 

The  users  environment  that  is  found  in  the  Enlisted  Evaluation  Program  is 
consistent  with  Microsoft  Windows  based  applications.  This  was  selected  for  several 
reason.  This  environment  is  required  for  government  applications  and  it  is  an  accepted 
industry  standard.  This  standard,  because  of  its  graphical  orientation,  is  easy  to  navigate 
through.  Tool  bars  and  menu  bars  allow  the  access  of  any  task  with  only  a  few  mouse 
command.  Icons  are  used  where  appropriate  to  represent  certain  tasks  or  applications. 
These  types  of  graphical  tools  allows  the  user  to  easily  navigate  without  remembering 
numerous  command  line  codes  and  typing  them  into  a  computer  to  access  or  manipulate 
information. 

3.  Development  Software:  ACCESS 

Access  is  a  Microsoft  Windows  application  used  for  the  development  of 
applications  that  require  a  relational  database  to  store  and  retrieve  information.  Access  ‘s 
relational  database  supports  the  industry  standard  of  a  windows  environment  and 
incorporates  sequel  queries  to  retrieve  information  from  its  underlying  data  structure.  It  is 
a  powerful  relational  database  which  allows  the  developer  to  create  a  working  computer 
model,  a  rapid  prototype,  through  the  use  of  pre-defined  commands  and  a  application 
device  called  the  “Wizard.” 
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The  development  of  a  rapid  prototype  using  Access  allows  for  the  creation  of  a 
windows  based  application  that  will  emulate  the  look  and  feel  of  other  windows  based 
applications.  Access,  or  any  application  developed  with  Access,  can  be  launched  from 
within  a  windows  environment  using  a  pull  down  menu  or  an  icon  that  represents  that 
application. 

B.  APPLICATION  OF  EVALUATION  PROGRAM 

1.  Purpose  of  the  Enlisted  Evaluation  Program 

The  Enlisted  Evaluation  Program  was  developed  to  provide  a  user  friendly 
graphical  user  interface  for  producing  U.S.  Navy  enlisted  evaluations.  The  graphical 
interface  incorporated  as  part  of  the  Enlisted  Evaluation  Program  is  intended  to  reduce  the 
amount  of  time  required  for  training  personnel  to  use  the  program  and  create  evaluations. 
For  those  users  who  are  experienced  user  this  Enlisted  Evaluation  Program  reduces  errors 
in  data  entry  by  using  pull-down  menus  for  selecting  input  items  and  field  formatting  for 
data  that  requires  entry  by  hand.  The  program  also  enables  the  use  of  one  set  of  data  for 
multiple  evaluation  thereby  reducing  repetitive  data  entry.  The  details  of  formatting  and  the 
use  of  pull-down  menus  will  be  covered  in  the  application  design  phase. 

2.  Problems  with  Current  Programs 

Evaluations  for  enlisted  personnel  are  usually  produced  using  a  DOS  based 
application.  These  applications  create  files  for  each  personnel  that  required  an  evaluation 
and  all  the  information  for  each  individual  must  be  typed  in.  When  creating  numerous 
evaluations  that  all  have  information  that  is  exactly  the  same  this  information  must  be  typed 
into  every  evaluation.  For  example.  Each  evaluation  has  a  block  labelled  “Conunand 
Address.”  This  information  is  the  same  for  every  evaluation  in  a  command  and  using  the 
DOS  based  programs  today  require  this  information  must  be  typed  into  each  evaluation.  A 
relational  database  has  the  compatibility  to  allow  the  user  to  select  the  “Command 
Address”  from  a  list,  requiring  no  typing  other  than  the  initial  one,  and  copy  that  entry  into 
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the  evaluation.  Repetitive  typing  is  a  major  draw  back  that  can  be  resolved  by  selecting 
information  from  a  list  instead  of  typing  it  in  every  where  it  is  needed  in  the  evaluation.  The 
written  text  that  must  be  included  in  the  comments  section  must  be  typed  in  using  a  word 
processor  and  imported  into  the  file  for  each  individual  evaluation.  This  text  can  not  be 
viewed  in  the  DOS  application  for  editing.  Any  editing  must  be  done  outside  the  program 
and  then  imported  again  into  the  DOS  application.  This  involves  the  opening  and  closing 
of  applications  for  each  evaluation  being  typed.  This  Enlisted  Evaluation  Program  does  not 
require  this  constant  exiting  and  entering  but  allows  for  the  editing  to  occur  inside  the 
program  using  the  editor  of  your  choice. 

3.  Why  use  the  Enlisted  Evaluation  Program 

The  Enlisted  Evaluation  Program  is  more  appealing  to  users  for  several  reasons. 
The  program  has  a  set  of  display  screens  that  are  intuitive  to  use  making  the  program  easy 
to  learn  and  use.  These  screens  are  set  in  a  Windows  environment,  familiar  to  most  every 
one  that  uses  a  personnel  computer.  Data  that  is  input  into  the  program  is  stored  in  a 
relational  database  and  can  be  recalled  for  use  bye  queries  and  subsequently  used  in  any 
evaluation  for  any  personnel,  this  allows  selections  to  be  made  from  pull  down  menus  with 
the  click  of  a  mouse  rather  than  typing  in  repetitive  data. 


27 


V.  ENLISTED  EVALUATION  PROGRAM  DESIGN 


The  Enlisted  Evaluation  Program  is  designed  following  the  phases  set  forth  in 
Debora  Mayhew’s  book  Principles  and  Guidelines  in  Software  User  Interface  Design,  [Ref. 
4].  The  phases  of  Scoping,  Functional  Specification,  Design  will  all  be  addressed  regarding 
the  construction  of  the  Enlisted  Evaluation  Program.  The  last  two  of  the  five  phases; 
Development  and  Testing/Implementation  have  not  been  completed  and  are  left  for  later 
research.  Limiting  the  number  of  phases  allows  for  a  more  manageable  scope  of  the  project 
to  be  completed  and  does  not  detract  from  the  idea  that  a  good  interface  design 
methodology  in  necessary  for  developing  a  quality  product.  In  addition  to  the  phases  of 
Debora  Mayhew  several  of  the  QFD  tools  will  be  used  in  gathering  and  organizing 
information  for  completing  several  of  the  phases  in  this  research. 

A.  SCOPING  PHASE 

The  Scoping  of  the  Enlisted  Evaluation  Program  involves  planning  the  project, 
conducting  a  user  profile  and  defining  the  hardware  and  software  requirements.  Usually  a 
business  definition  and  a  business  requirements  analysis  is  conducted  to  begin  the  decision 
to  develop  a  new  product.  These  two  documents  begin  the  formatting  of  the  idea  to  be 
developed.  The  need  is  first  established  and  digitalis  about  these  needs  are  gathered  from 
marketing  or  users  and  the  project  plan  begins  to  form 

1.  Project  Plan 

The  project  plan  for  the  Enlisted  Evaluation  Program  is  not  complicated  or 
extensive.  The  development  of  the  program  is  rooted  in  the  need  for  a  shipboard  Windows 
evaluation  program  that  would  reduce  the  time  and  effort  to  create  a  new  evaluation.  A 
requirement  analysis  of  several  users  that  have  experience  with  existing  software  revealed 
a  dissatisfaction  with  the  current  interface  and  the  functionalities  of  the  programs  in  use. 
Staffing  and  cost  of  the  project  must  also  be  considered  and  in  the  case  of  the  Enlisted 
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Evaluation  Program  the  staffing  is  one  and  the  cost  was  the  price  of  obtaining  the 
developmental  software.  Access  by  Microsoft  Windows. 

2.  User  Profile 

The  users  of  the  Enlisted  Evaluation  Program  will  be  both  enlisted  and  officers. 
These  individuals  are  relatively  computer  literate,  motivated,  and  experienced  at  their  job. 
Generally  the  officers  of  a  command  complete  all  the  details  of  the  evaluation  and  a 
yeoman  would  check  for  format  and  fill  out  the  summary  blocks  for  each  evaluation  prior 
to  having  the  reporting  senior  sign  each  of  the  evaluations.  All  of  the  users  interviewed 
indicated  a  familiarity  with  Windows  based  applications  and  all  of  the  users  have  a 
familiarity  with  personnel  computers  and  the  use  of  word  processing  software  used  on 
computers.  Emulating  the  Windows  environment  and  using  familiar  word  processing 
software  will  reduce  the  time  required  to  adequately  learn  the  program.  All  the  users 
indicated  a  familiarity  with  evaluations  and  the  data  entry  fields  on  the  forms.  This 
familiarity  is  used  to  ease  the  learning  of  the  programs  data  entry  by  matching  the  entry 
names  on  the  computer  screen  to  the  names  on  the  evaluations.  Both  ease  of  use  and  ease 
of  learning  will  be  stressed  in  the  development  of  the  screens  of  the  Enlisted  Evaluation 

Program. 

3.  Hardware  and  Software  Definition 

a.  Hardware  Requirements 

The  Enlisted  Evaluation  requires  an  IBM  PC  compatible  computer  that  has 
the  features  listed  in  Figure  10  on  page  31.  This  is  the  minimum  requirement  for  a 
respectable  performance,  any  additional  hardware  such  as  a  faster  CPU,  more  RAM  or 
faster  hard  drive  will  improve  performance  of  your  program. 

b.  Software  Requirements 

The  software  requirements  are  listed  in  Figure  11.  The  software  that  is  used 
for  word  processing  can  very  but  must  conform  with  Object  Linking  and  Embedding 
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Version  2.0  (OLE  2.0).  This  linking  standard  allows  a  text  document  of  the  word  processor 
to  be  stored  and  viewed  in  the  database.  While  it  is  stored  in  the  database  entering  and 
exiting  the  application  is  not  required  to  view  the  document. 

1:386,486CPU/33MHZ 
2:  40  Megabyte  Hard  Drive 
3:  4  Megabytes  Ram 


Figure  10:  Hardware  Requirements 


1;  Microsoft  Windows  3.X 
2:  Microsoft  Access  2.0 

3:  Microsoft  Word  3.5  (any  word  processor  with  OLE  2.0) 


Figure  11:  Software  Requirements 


B.  FUNCTIONAL  SPECIFICATION  PHASE 

This  phase  focuses  on  Task  Analysis,  User  Interface  Goal  Setting,  and  Training  and 
Documentation  Definition.  The  Task  analysis  was  conducted  with  surveys  of  the  users  to 
consolidate  their  desires.  The  Task  analysis  also  involved  interviews  of  several  users  to 
reveal  any  latent  requirements  that  users  did  not  realize  today  s  technology  offered  them. 
Specifics  on  User  Interface  Goal  Setting  and  Training  and  Documentation  Definition  were 
not  analyzed. 
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1.  Task  Analysis 

The  Task  Analysis  for  the  Enlisted  Evaluation  Program  was  conducted  using 
interviews  and  the  survey  form.  The  input  given  by  the  users  was  organized  into  an  Affinity 
diagram  where  the  users  inputs  could  be  correlated  into  technical  characteristics.  The  first 
interview  process  revealed  the  required  functionality  of  the  Enlisted  Evaluation  Program. 
This  list  produced  the  foundation  of  characteristics  that  the  program  will  have. 

a.  Required  Functionality 

The  functionality  of  any  evaluation  program  must  enable  the  user  to  print 
out  a  enlisted  evaluation  in  the  proper  format  with  all  its  copies  to  be  submitted  as  a  final 
evaluation  into  a  service  record.  The  functionalities  included  in  this  program  were 
compiled  from  user  inputs  as  well  as  its  designer.  Although  there  are  not  many  in  the  list  in 
Figure  12  on  page  33  implementing  these  in  a  graphical  user  interface  is  not  a  trivial  matter. 
All  of  the  required  functionalities  were  included.  Each  of  the  functionalities  listed  is  a 
written  statement  or  sentence  to  better  convey  its  meaning. 

b.  User^s  Functional  Inputs  of  Prototype 

The  user  functional  inputs  of  the  prototype  involve  a  designer  showing  the 
Enlisted  Evaluation  Program  to  several  users  for  inputs  on  how  it  likes  the  navigational 
features,  radio  buttons,  pull-down  menus  and  other  interface  features  that  effect 
functionality.  All  of  the  subjects  in  this  study  were  Naval  officers  with  fleet  experience. 
After  reviewing  the  prototype  the  users  requested  the  following  inputs  found  in  Figure  13 

on  page  35 
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1 :  Enter  ships  divisions 

2:  Enter  ships  reporting  senior  including  full  name,  rank, 
title,  SSN. 

3:  Enter  ship  or  station  address. 

4:  Enter  and  edit  crew  information  including  full  name, 
rate,  date  of  rate,  last  report  date,  ratings,  branch  or  class, 
date  reported,  status,  SSN. 

5:  Create  evaluations  that  print  the  form  of  a  standard 
enlisted  evaluation. 

6;  Select  or  create  more  than  one  evaluation  for  a  crew 
member  and  be  able  to  enter  or  change  period  of  report 
to,  period  of  report  from,  type  of  report,  occasion  for 
report,  advancement  recommendation,  reserve  part,  date 
signed,  physical  readiness,  and  all  grades  for  the  required 
categories. 

7:  Enter  text  for  duties  and  comments  section  of  the 

evaluation  with  the  capability  to  underline  and  bold  face 
type  any  character. 

8:  Enter  numbers  for  summary  information  for  each  grade 
on  the  evaluation  form. 

9:  Print  and  preview  drafts  and  final  copies  of  the 

evaluations  including  the  OCR,  bupers,  field,  member, 
and  activity  copy  in  the  fonts  required  bye  the  Navy. 


Figure  12:  Functional  Requirements 
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C.  DESIGN  PHASE 

The  design  phase  involves  the  following  user  interface  design  methods  mentioned 

bellow; 

•  User  Interface  Mock-up 

•  Style  guide 

•  Detailed  user  Interface  Design 

•  User  interface  Prototyping 

•  Prototype  User  Interface  test  plan 

•  Prototype  User  Interface  Testing 

These  methods  of  Deborah  Mayhew  are  discussed  in  detail  in  [Ref.  4].  The  first  area 
of  this  phase  involved  a  user  interface  mock  up  of  the  system.  This  involved  the 
development  of  a  rapid  prototype  using  the  developmental  software  Access  By  Microsoft. 
This  prototype  was  constructed  using  the  government  style  guide  in  [Ref.  3].  The  User 
Interface  Mock-up  was  modified  to  create  a  Detailed  user  Interface  Design  which  was  later 
used  in  the  Prototype  user  interface  testing  phase. 

1.  User  Interface  Mock-up 

This  mock-up  is  based  on  the  user  profile,  the  hardware  and  software  definition,  the 
task  analysis  and  organized  in  to  the  primary  display  screens  the  user  would  navigate 
through.  The  Style  Guide  method  is  incorporated  into  this  phase  as  well  and  described  in 
detail  in  [Ref.  3].  The  style  guide  for  the  program  was  produced  by  the  government  and  is 
required  to  be  followed  for  developing  windows  based  applications.  The  use  of  the  rapid 
prototype  software  Access,  allowed  the  User  Interface  Mock-up  to  be  completed  relatively 
quickly.  The  interface  mock-up  produced  the  look  and  feel  of  the  screens  but  the  screens 
do  not  have  the  data  manipulation  features  of  the  relational  database  added  in.  These 
features  are  added  in  the  detailed  use  interface  design  phase.  These  screens  are  described 
and  shown  in  detail  in  the  next  section. 
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2.  Detailed  User  Interface  Design 

This  phase  incorporates  the  screens,  user  input  formats,  error  messages,  and 
complete  working  functionality.  Again,  these  screens  and  functionalities  must  adhere  to  the 
style  guide  discussed  earlier.  All  the  screens  in  the  Enlisted  Evaluation  Program  contain 

1 :  When  moving  from  front  to  back  of  evaluation  have  the 
individual  you  were  working  on  be  inunediately  displayed 
so  you  do  not  need  to  select  him  from  the  group. 

2:  Create  a  button  that  will  make  all  the  grades  for  an 
individual  Not  Observed. 

3:  Be  no  more  than  three  mouse  clicks  away  from  any  screen. 

4:  Be  able  to  use  it  with  any  word  processing  software. 

5:  Support  importing  text  files  and  have  the  capability  to  use 
bold  face  text  and  underline  characters. 

6:  Use  proper  fonts  required  by  Navy:  OCR  A  and  Courier. 

Be  able  to  easily  change  these  for  new  requirements. 

7:  Have  security  so  division  officers  can  not  see  the  file  of 
someone  who  is  not  in  their  division. 

8:  print  multiple  evaluations  based  on  a  division,  rate,  or 
period  of  report  to  date. 

Figure  13:  User  Inputs 

tool-bars  and  pull-down  menus.  The  pull-down  menus  are  design  to  maneuver  from  one 
screen  to  another  with  the  fewest  mouse  movements  The  tool  bars  are  designed  to  perform 
frequently  used  tasks  for  each  of  the  screens.  The  program  incorporates  several  screens  that 
are  linked  together  for  creating  an  evaluation  for  an  enlisted  person.  The  screens  are  design 
so  shared  data  can  be  used  by  everyone  using  the  program.  Enlisted  evaluations  contain  two 
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types  of  information.  Information  common  to  all  crew  members  and  information  specific 
for  a  certain  crew  member.  A  ships  reporting  senior  and  his  pertinent  information  is  data 
that  will  be  found  in  eveiy  evaluation  and  be  identical.  The  name,  rank,  and  social  security 
number  of  one  reporting  senior  can  be  found  on  hundreds  of  evaluations  and  does  not  need 
to  be  typed  for  each  evaluation.  A  certain  crew  members  social  security  number  is  specific 
for  that  crew  member.  Information  about  the  ship,  its  reporting  seniors  and  evaluation 
summaries  will  usually  be  entered  by  Yeoman  in  the  commands  office.  Data  specific  to  a 
crew  member  such  as  their  write  up  in  the  comments  section  and  specific  evaluation  grades 
will  be  entered  by  the  division  officer  or  whoever  is  tasked  to  write  the  evaluation.  All  the 
necessary  information  necessary  to  produce  an  evaluation  is  provided  for  in  the  program 
and  presented  on  the  screens. 

a.  Pull  Down  Menu  Selections 

Before  discussing  the  screens  a  description  of  the  pull-down  menu  should 
be  given.  This  menu  is  common  to  all  the  screens  with  very  few  exceptions.  It  was  used  so 
users  could  easily  navigate  to  any  part  of  the  program  by  simply  pulling  down  the  menu 
and  selecting  the  area  they  desire  to  go.  The  pull-down  menu  found  in  Figure  14  on  page 
37  is  representative  of  the  menus  found  in  all  the  screens. 

b.  Password  Screen 

The  password  screen  is  shown  in  Figure  15  on  page  38.  This  screen  is  the 
first  screen  to  be  displayed  when  the  ICON  for  the  Enlisted  Evaluation  Program  is  double 
clicked  with  a  mouse.  This  screen  will  determine  whether  the  individual  logging  on  will 
acquire  access  to  the  program.  An  individual  must  type  in  their  name  and  password  which 
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is  verified  with  the  internal  listing  of  the  same.  If  the  password  is  found  is  granted  and  the 
main  screen  is  displayed. 


Exit  Personnel  --> 

Ships  Information  --> 

Enter  or  Edit  Crew 

Division  Names 

Evaluations  — > 

Enlisted 

Print 

Summary  (block  40) 

Reporting  Seniors 

Figure  14:  Pull-Down  Menu  Screen 


c.  Main  Screen 

The  main  screen  is  shown  in  Figure  16  on  page  39  and  opens  after 
successfully  logging  on  to  the  program.  As  displayed  in  the  figure  the  user  has  several 
choices;  editing  or  creating  a  new  evaluation,  enter  or  edit  crew  member,  or  print 
evaluations.  The  same  commands  are  found  in  the  pull-down  menu  but  beginners  who  used 
the  program  expressed  desires  to  have  those  choices  prevalent  when  they  first  entered  the 
system. 

d.  Reporting  Seniors  Screen 

The  reporting  seniors  screen  is  usually  filled  out  by  the  commands  yeoman 
or  a  designated  administrative  worker.  This  screen  lists  all  the  senior  officers  in  the 
command  that  are  eligible  to  be  the  final  signature  authority  on  enlisted  evaluations. 
Reporting  seniors  can  be  added  or  edited  from  this  screen  and  includes  all  of  the  pertinent 
information  about  each  reporting  senior  that  can  be  found  on  an  enlisted  evaluation.  The 
reporting  seniors  screen  also  contains  the  ship  or  station  address  which  will  be  entered  on 
all  evaluations.  The  Reporting  seniors  screen  is  presented  in  Figure  17  on  page  41. 
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Microsoft  Access  -  [Enter  Password] 


Figure  15:  Password  Screen 


Exit  Personnel  Ship  Information 


Figure  16:  Main  Screen 


e.  Evaluation  Summary  Screen 

All  enlisted  evaluations  contain  summary  boxes  that  list  the  number  of 
servicemen  and  women  that  have  been  ranked  under  a  certain  grade.  This  screen  allows  you 
to  select  the  group  of  individuals  by  rank  that  you  desire  to  enter  summary  information  for. 
After  selecting  the  rank  or  pay-grade,  the  final  date  of  the  evaluation  and  the  number  of 
servicemen  and  women  can  be  entered  for  each  grade  in  an  evaluation.  The  Evaluation 
Summary  Screen  in  Figure  18  on  page  43  shows  group  E-7  and  above  and  will  allow  you 
to  enter  or  change  the  “period  of  report  to  date”  and  type  in  the  number  of  personnel  that 
are  marked  under  each  grade.  The  “period  of  report  to  date”  is  the  end  date  of  the 
evaluation.  This  screen  will  normally  be  filled  out  after  all  evaluations  are  turned  in  for 
final  signature  so  a  yeoman  or  administrative  assistant  will  manipulate  this  screen. 

/  Crew  Entry  or  Edit  Screen 

The  crew  entry  or  edit  screen  prompts  the  user  to  select  a  division  and  crew 
member  to  edit  or  select  the  new  record  button  to  enter  a  new  crew  member  into  the 
database.  New  crew  member  can  not  be  added  to  the  database  unless  there  is  a  minimum 
set  of  information  to  store.  The  program  will  not  store  a  table  that  does  not  contain 
information  in  it.  An  individual  must  have  a  social  security  number,  be  part  of  a  division, 
and  have  a  reporting  senior  in  order  to  be  stored  in  the  database.  This  information  is 
required  because  the  sequel  queries  that  manipulate  data  require  this  specific  data  to  be  in 
place  so  the  program  can  sort  the  information  in  the  database.  Several  of  the  selections  have 
pull-down  menus  associated  with  their  specific  data  entry.  These  menus  give  the  user  a 
finite  list  of  data  to  choose  from  that  is  required  for  that  specific  data  block  for  a  specific 
crew  member.  Requiring  a  simple  selection  to  input  text  can  eliminate  typographical  errors 
for  that  specific  block  and  it  can  also  eliminate  erroneous  entries.  Some  of  the  entry  fields, 
like  the  “Date  Of  Rate”  fields  are  limited  in  length  to  seven  characters  and  require  a  certain 
format  that  must  be  printed  on  to  an  evaluation  for  it  to  be  acceptable.  The  format  for  all 
date  entries  permit  only  seven  characters  to  be  entered.  The  order  and  type  of  characters 
entered  begin  with  the  last  two  numbers  of  the  year  followed  by  the  first  three  letters  of  the 
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Microsoft  Access  -  [Reporting  Seniors] 


Figure  17:  Reporting  Seniors  Screen 


month  then  the  day  of  the  year.  This  format  will  resemble  this;  95MAR23.  The  characters 
that  make  up  the  month  part  in  the  date  field  are  all  automatically  capitalized  by  the  Enlisted 
Evaluation  Program.  The  Enlisted  Evaluation  Program  limits  the  users  data  entry,  in  the 
case  of  a  date  field,  to  these  requirements.  Other  fields  such  as  Ratings  represent  a  pull¬ 
down  menu  with  a  finite  number  of  selections.  There  are  only  enlisted  ratings  from  E-1  to 
E-9  and  those  are  the  only  selections  a  user  can  select  from  the  pull  down  menu  and  have 
accepted  in  this  data  field.  If  a  user  tries  to  type  data  in  that  does  not  match  one  of  these 
built  in  formats  it  will  not  be  accepted  by  the  program.  This  entry  form  is  displayed  in 
Figure  19  on  page  44. 

g.  Front  of  Evaluation  Screen 

The  front  of  the  evaluation  screens  provides  for  pull  down  menus  to  enter 
data  that  has  a  finite  number  of  inputs.  Again  the  user  can  select  an  exiting  crew  member 
from  the  menus  then  determine  whether  to  create  a  new  evaluation  or  modify  and  existing 
evaluation  for  the  crew  member  he  has  selected.  The  rating  and  division  selection  boxes 
generate  queries  to  limit  the  names  the  user  selects  from  to  limit  the  amount  of  crew 
members  displayed.  This  will  prevent  users  from  having  to  search  through  all  the  names  in 
the  crew  just  to  find  the  crew  member  the  user  is  looking  for.  Evaluations  for  the  same  crew 
member  are  sorted  by  crew  name  and  date  allowing  multiple  evaluations  for  each  crew 
member.  Pull-down  menus  are  also  utilized  to  limit  the  data  entry  selections  on  the  front  of 
the  evaluation  page.  This  screen  is  the  first  in  the  program  to  use  radio  buttons  to  reduce 
the  amount  of  data  entry.  Radio  buttons  are  used  in  order  to  complete  multiple  entries  with 
just  one  command  by  filling  in  all  the  grading  categories  with  “not  observed”  or  four  point 
zero  grades.  Although  the  menu  bar  at  the  top  allows  navigation  between  all  screens  this 
form  also  has  command  buttons  that  will  move  you  to  one  of  the  next  logical  screens  after 
editing  the  front  of  the  evaluation.  From  this  screen  you  are  likely  to  edit  the  back  or  print 
out  an  evaluation,  these  buttons  are  located  at  the  top  of  the  screen  in  Figure  20  on  page  46 
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Microsoft  Access  -  [Summary  Blocks] 


^3 


Figure  18:  Evaluation  Summary  Screen 


Microsoft  Access  -  [Enter/Edit  Crew  Member] 


Figure  19:  Crew  Entry  or  Edit  Screen 


h.  Back  of  Evaluation  Screen 

The  back  of  the  evaluation  was  the  most  difficult  to  emulate.  This  screen 
involves  incorporating  a  text  editor  and  storing  this  text  in  the  relational  database.  Again 
users  can  select  the  division  and  name  of  the  personnel  they  desire  to  edit  and  the  evaluation 
date  for  that  specific  crew  member.  Instructions  at  the  top  of  the  editing  space  instruct  you 
to  click  you  mouse  in  one  of  the  boxes,  either  duties  or  comments  box,  and  follow  the 
commands  to  insert  an  object.  The  object  that  will  be  stored  in  the  relational  database  is  a 
text  file  created  with  a  word  processor.  You  will  then  be  prompted  to  choose  the  type  of 
object  you  wish  to  insert  by  choosing  from  a  list  of  word  processing  software  you  have 
stored  on  your  computer.  The  software  that  will  be  displayed  in  the  box  not  only  must  be 
on  your  computer  but  it  must  support  OLE  2.0.  After  selecting  the  software  you  will  use, 
like  Microsoft  Word,  that  specific  application  is  launched  inside  of  the  Enlisted  Evaluation 
Program  and  is  displayed  in  the  box  you  clicked  with  your  mouse.  The  back  of  the 
evaluation  screen  with  the  word  processor  being  used  is  shown  in  Figure  21  on  page  47. 
From  here  you  enter  the  text  in  the  proper  format  that  will  be  printed  on  the  back  of  the 
evaluation  form.  To  exit  you  word  processing  software  you  click  with  your  mouse  on  any 
object  on  the  button  labeled  editing  complete  and  continue  with  another  task. 

I.  Print  Screen 

The  print  screen  for  evaluations  was  created  with  the  same  format  as  the 
others.  Selecting  the  crew  member  to  be  displayed  is  done  in  the  same  way  with  division 
and  rating.  Following  this  the  user  can  select  the  crew  member  and  evaluation  date  to  be 
printed.  The  users  can  either  print  or  preview  the  front  or  back  of  the  enlisted  evaluations. 
The  radio  buttons  that  are  labeled  Evaluation  Copies  Front  and  Back  are  used  to  print  out 
final  copies  of  the  evaluation.  These  buttons  will  print  four  copies  of  the  evaluations  final 
version.  This  will  include  the  bupers,  filed,  activity,  and  members  copy  and  the  OCR  copy 
of  the  front  or  back  part  of  the  evaluation.  The  top  radio  buttons  labeled  Evaluation  Front 
and  Back  only  print  out  one  copy  to  allow  revisions  to  be  edited  by  hand  before  the  final 
copies  are  printed.The  print  evaluations  screen  is  depicted  in  Figure  22  on  page  48. 
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Figure  20:  Front  of  Evaluation  Screen 


Exit  Personnel  Ship  Information 


Figure  21:  Back  of  Evaluation  Screen 


Microsoft  Access  -  [Printing  Selections] 
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Figure  22:  Print  Evaluation  Screen 


D.  PHASES  AND  METHODS  NOT  COVERED 

The  Development  and  Testing/Implementation  phases  of  Mayhew  were  not 
covered  to  minimize  the  scope  of  the  research.  User  Interface  Prototyping  and  Prototype 
User  Interface  Test  Plan  were  also  not  completed  because  the  Enlisted  Evaluation  Program 
does  not  contain  all  the  functionality  required  a  fully  developed  prototype.  The  program  is 
fully  functional  and  is  able  to  receive  data  and  organize  it  for  printing  multiple  evaluations 
but  there  is  no  help  screen  for  the  program.  Ideally  the  program  should  be  developed  with 
Microsoft’s  developers  tool-kit  for  Access.  This  would  allow  the  program  to  run  without 
having  the  software  for  Access  installed  on  your  computer.  In  addition,  the  program  did  not 
go  through  a  usability  test  to  reveal  any  major  problems  in  the  initial  design.  Final 
implementation  was  constricted  to  a  few  users  only  testing  the  core  functionality  of  the 
program. 
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VI.  DESIGN  AND  IMPLEMENTATION 


A.  DESIGN  GOALS  AND  DEVELOPMENT 

1.  Design  Goals 

The  design  goals  of  this  research  was  to  prototype  a  windows  based  evaluation 
program  for  editing  and  printing  enlisted  evaluations.  This  prototype  needed  to  conform 
with  government  standards  in  [Ref.  3]  at  the  same  time  maintaining  a  consistency  among 
screens  to  facilitate  familiarity  with  the  program  and  an  easy  to  leam  graphical  user 
interface.  The  Enlisted  Evaluation  Program  is  developed  in  the  Microsoft  Windows 
environment  using  the  developmental  database  software  Access.  Access  was  ideal  to  use 
as  a  rapid  prototyping  tool  for  this  application  because  it  allows  developers  to  create 
windows  based  interfaces  with  a  underlying  relational  database.  Access’  tools  can  create 
pull-down  menus,  radio  buttons,  colorful  screens,  and  any  mouse  selectable  option 
normally  found  in  a  windows  environment. 

2.  Development  Goals 

The  phases  of  development  involved  analysis  of  current  windows  programs, 
implementing  desired  functionalities,  and  the  stmcture  of  the  Enlisted  Evaluation  Program. 
Developing  a  program  that  produces  an  enlisted  evaluation  program  was  chosen  for  several 
reasons.  The  first  of  these  reasons  is  no  windows  based  evaluation  program  that  uses  a 
relational  database  and  the  second  reason  is  the  program  has  the  ability  to  be  expanded  to 
support  other  administrative  functions.  The  program  was  also  chosen  because  it  represents 
a  finite  goal;  produce  an  enlisted  evaluation  in  the  proper  format.  The  Enlisted  Evaluation 
Program  utilized  data  that  is  already  entered  in  SNAP  with  very  few  exceptions.  Because 
this  information  is  present  in  SNAP  including  this  type  of  functionality  into  NTCSSAM 
would  not  be  as  involved  as  other  functionalities. 

The  implementation  of  the  functionalities  was  centered  around  reducing  the 
possibilities  of  error  that  a  user  could  make  and  reducing  the  time  required  to  create  the 


51 


evaluation.  Reducing  errors  from  users  can  be  accomplished  in  several  ways  and  Access 
provided  for  this  with  several  of  its  built  in  tools.  Entry  boxes  can  have  a  format  assigned 
to  each  box.  When  users  are  asked  to  type  in  a  crew  members  middle  initial  and  they  type 
the  number  seven  the  field  in  the  box  does  not  accept  the  entry.  Entering  dates  into  boxes 
is  also  controlled  by  formatting  the  field  to  prevent  improper  entry.  All  the  date  entrees 
require  two  numbers  followed  by  three  letters  then  two  numbers  to  result  in  an  entry  similar 
to  this:  90MAR30.  The  entry  box  will  automatically  make  the  letters  capitalized  as  required 
in  the  evaluation  form.  Another  Access  tool  that  facilitates  data  entry  and  the  reduction  of 
errors  is  a  pull  down  list.  If  there  is  a  finite  number  of  entries  for  a  specific  box  having  the 
user  select  form  those  will  reduce  the  errors  of  typing  and  format,  the  front  of  the  evaluation 
has  several  of  these  type  of  entry  boxes.  The  entry  box  “Type  of  Report”  only  has  three 
possible  entries  for  that  specific  box;  Concurrent,  Special,  Separation.  Just  by  selecting  one 
of  these  and  not  typing  in  the  field  prevents  erroneous  errors  and  saves  time.  Time  spent  by 
the  user  filling  in  boxes  can  also  be  save  by  using  a  radio  button  to  fill  in  numerous  fields 
with  one  selection.  Frequently  commands  are  required  to  give  grades  of  “not  observed”  for 
all  the  areas  being  grades.  Radio  buttons  that  fill  in  all  thirteen  fields  with  not  observes 
reduces  entry  time  dramatically. 

The  development  of  the  Enlisted  Evaluation  Program  centered  around  the  logical 
development  of  the  screens  and  how  data  entry  would  be  divided  between  them.  The 
structure  of  the  screens  and  the  logical  flow  of  navigating  between  screen  is  also  a 
consideration  for  creating  a  program  that  is  easy  to  use  and  learn.  Each  of  the  screens 
should  be  divided  into  logical  groups  of  data  entry  and  emulate  the  natural  progression  of 
constructing  an  evaluation  in  the  same  way  you  would  without  using  a  program.  Creating 
a  logical  path  for  the  construction  of  an  evaluation  enhances  the  use  of  the  program  and 
makes  the  program  easier  to  learn.  If  the  order  of  data  input  mirrors  the  way  evaluations  are 
normally  constructed  bye  the  user  then  creating  an  evaluation  will  be  more  intuitive. 
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B.  IMPLEMENTATION  OF  DESIGN 


1.  Design  of  Enlisted  Evaluation  Program 

Each  of  the  screens  developed  have  the  same  characteristics  and  the  same 
backgrounds,  headings,  and  pull-down  menus  where  applicable.  This  includes  the  same 
color  scheme,  exit  button,  tool  bar,  and  menu  bar  as  well  as  other  similarities.  Familiarity 
among  screens  makes  for  smother  navigation  and  friendlier  environment  [Ref.  10].  The 
specific  design  of  the  screens  is  divided  into  three  areas  of  logical  data  entry;  information 
about  the  command,  crew  information  that  does  not  change,  information  specific  to  a 
certain  evaluation  for  that  crew  member.  Command  information  is  divided  into  three 
screens.  One  where  users  input  information  about  the  ship  or  station  and  the  reporting 
seniors,  another  to  input  division  names,  and  the  third  for  evaluation  summary  information. 
Command  information  screens  and  some  crew  information  does  not  change  when  creating 
a  new  evaluation,  and  in  the  case  of  command  information  this  information  can  be  used 
when  creating  any  evaluation  because  it  never  changes  for  any  crew  member.  For  example 
the  ships  address  is  used  in  all  evaluations.  The  evaluation  front  and  back  screens  represent 
data  specific  to  each  evaluation  for  one  crumblier.  Crew  members  evaluations  are  identified 
by  the  crew  members  name  and  the  date  of  the  evaluation.  A  crew  member  will  not  change 
his  name  but  different  evaluations  for  that  crew  member  need  to  be  identified.  The  crew 
members  name  and  date  of  report  together  separate  the  different  evaluations  for  that  one 
crew  member.  Selecting  crew  members  for  printing  and  editing  are  the  same  for  three  of 
the  screens.  Both  the  front  and  back  evaluation  screen  and  print  screen  have  the  identical 
display  to  select  rating  and  division  before  selection  the  specific  crew  member.  This 
duplication  of  format  enhances  familiarity  with  the  program  and  how  to  display  the  desired 
information  about  a  crew  member.  Command  buttons  are  found  frequently  on  screens  and 
are  used  for  navigation  in  the  program  and  also  used  for  action  buttons  for  specific  screens. 
The  pull  down  menu  on  the  top  of  the  program  screen  will  allow  you  to  navigate  to  any 
screen  in  the  program,  but  certain  screens  have  command  buttons  that  navigate  to  the  next 
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logical  screen  when  creating  an  evaluation.  The  evaluation  front  screen  has  two  command 
buttons  for  navigation;  “Edit  Evaluation  Back”  and  “Evaluations  Print”.  These  two  buttons 
were  added  for  logical  navigation.  It  goes  to  reason  that  after  you  finish  with  the  front  of 
the  evaluation  you  will  want  to  work  on  the  back,  if  not  you  may  want  to  print  out  what  you 
have  worked  on.  All  the  screens  have  command  buttons  to  exit  which  automatically  saves 
all  the  work  you  have  done  before  leaving  the  Enlisted  Evaluation  Program.  Radio  buttons 
were  used  in  two  instances  in  the  program.  The  Front  of  Evaluations  screen  has  two  radio 
buttons  to  make  all  the  grades  four  point  zero  or  not  observed.  These  are  the  most  common 
entries  for  evaluations  and  these  buttons  automatically  make  selections  for  each  of  the 
thirteen  graded  categories  of  the  evaluation.  The  print  screen  also  used  radio  buttons  to 
select  between  four  different  items.  These  buttons  allow  for  different  options  of  printing 
and  preview  for  the  front  and  back  of  evaluations  both  for  the  draft  and  final  copies.  Pull¬ 
down  boxes  were  used  in  numerous  places  in  the  program.  The  pull-down  boxes  are  used 
for  entries  with  a  finite  lists  of  data  that  is  allowed  in  the  entry  box.  For  information  you 
type  in  like  divisions  on  a  ship  or  ratings  there  are  only  a  finite  number  of  divisions  and 
nine  ratings  that  are  in  the  Navy,  E- 1  to  E-9.  Entiy  boxes  that  can  only  be  filled  with  a  finite 
number  of  entries  are  best  served  with  pull  down  boxes  because  it  reduces  the  amount  of 
typing  an  minimizes  errors.  The  list  in  Figure  15  on  page  55  represents  all  the  objects  in  the 
Enlisted  Evaluation  Program  where  a  pull-down  box  is  used  to  select  and  fill  in  the  entry 
box  with  data. 

Screen  size  is  a  limiting  factor  when  determining  the  number  of  items  that  are 
included  on  one  screen.  Groups  of  data  that  can  be  organized  in  some  logical  part  or  that 
have  a  logical  correlation  should  be  placed  on  one  screen.  This  grouping  simulates  starting 
with  an  idea  then  finishing  with  it  before  moving  on  to  the  next  idea.  Each  one  of  the 
screens  represent  one  idea  and  the  items  requiring  data  entry  in  that  screen  are  part  of  that 
idea.  For  example  the  front  of  the  evaluation  screen  fills  in  all  the  data  that  is  required  for 
the  front  of  the  evaluation.  Users  can  look  at  the  evaluation  form  and  the  evaluation  screen 
and  see  all  the  items  from  one  side  of  the  evaluation  form  are  present  on  the  screen.  The 
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naming  of  the  boxes  on  the  screen  also  correlate  to  the  names  of  the  boxes  on  the  form  to 
minimize  any  confusion  about  what  information  goes  in  what  box.  One  of  the  more  difficult 
design  considerations  was  providing  for  the  use  of  a  text  editor  or  a  text  editor  capability 
while  the  Enlisted  Evaluation  Program  was  running.  Exiting  in  and  out  of  two  programs  to 


1 :  Division  Name 

2:  Reporting  Senior 

3:  Ratings 

4:  Status 

5:  Branch/Class 

6:  Summary  group 

7 :  Period  of  Report  To 

8:  Type  of  Report 

9:  Occasion  fro  Report 

10:  Advancement  Recommendation 

11:  Date  Signed 

12:  Physical  Readiness 

13:  All  graded  sections  that  require  numeric  score. 
14:  Selection  of  rating  and  division 
15:  Selection  of  crew  member 


Figure  23:  Evaluation  Boxes  with  Pull-Down  Menus 


edit  text  then  manage  data  in  a  database  is  unacceptable.  Access  works  its  way  arround  this 
problem  through  the  use  of  Object  Linking  and  Embedding  2.0.  This  allows  the  user  to 
manipulate  text  inside  the  program  and  not  switch  in  and  out  to  edit  text.  Microsoft  Word 
is  word  processing  software  that  sports  OLE  2.0  and  enables  the  user  to  edit  a  document 
inside  of  the  Enlisted  Evaluation  Program  while  you  are  in  the  program.  Programs  with  the 
capability  of  OLE  2.0  will  behave  in  the  same  manner.  The  screen  size  that  is  required  to 
fit  the  text  boxes  on  an  evaluation  exceeds  the  size  of  a  typical  1 5”  computer  monitor  whose 
resolution  is  set  at  800X600  dots  per  inch.  This  limitation  required  the  use  of  a  scroll  bar  to 
access  both  the  duties  and  comments  box  found  on  the  back  of  the  evaluation  form. 
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VII.  SUMMARY  OF  EVALUATION  PROGRAM 


A.  FUNCTIONALITY  NOT  INCLUDED 

The  functionality  limitations  or  omissions  may  or  may  not  be  related  to  the 
limitation  of  the  software.  Some  of  the  functionalities  were  not  explored  as  a  result  of  the 
limitations  of  thesis  work.  The  functionalities  that  were  not  included  begin  with  moving 
from  screen  to  screen.  When  users  moved  from  the  front  of  the  evaluation  screen  to  the 
back  of  the  evaluation  screen  the  crew  member  you  were  working  on  the  front  evaluation 
screen  should  show  up  when  you  switch  to  the  back  of  the  evaluation  screen.  Another 
involved  Inserting  text  required  too  many  mouse  clicks  and  proved  to  be  more  awkward 
when  using  other  software  that  was  not  made  by  Microsoft.  Word  Perfect  text  could  not  be 
imported  into  the  document  only  text  files  from  word  perfect  could  be  entered  into  an  OLE 
program  and  then  used.  Selecting  more  than  one  name  for  printing  would  allow  multiple 
evaluations  to  be  printed  with  only  one  print  command.  The  program  should  allow  for 
printing  the  final  version  for  all  evaluations  of  a  given  group,  like  all  E-6  evaluations.  The 
evaluations  should  print  the  front  and  back  of  the  evaluation  at  the  same  time  so  the  user 
does  not  need  to  flip  the  paper  on  a  double  sided  copy.  The  default  fonts  should  be 
automatically  set  when  you  open  a  new  duties  or  comments  box. 

B.  DEVELOPMENT  CONSTRAINTS 

The  most  notable  of  the  limitations  is  the  specific  requirements  of  security  for 
evaluations.  Access  provides  for  security  in  a  manner  where  you  either  have  access  to  a 
screen  or  you  do  not.  Access  will  not  separate  and  prevent  two  division  officers  from 
accessing  the  evaluation  information  of  the  others  division.  You  can  prevent  others  from 
using  the  program  at  all  but  there  is  no  provision  for  partial  security  using  the  same  queries 
and  screens.  Separate  software,  The  Access  Developers  Kit,  is  required  to  develop  just  a 
run  time  module  so  the  inner  workings  of  the  program  cannot  be  changes  by  a  system 
administrator.  The  graphics  for  the  front  of  the  evaluation  requires  a  large  amount  of 
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memory  do  display  on  the  screen.  System  crashes  occurred  while  operating  in  true  color 
resolution.  Not  all  the  commands  are  written  in  the  object  oriented  program  language 
provided  with  Access.  This  is  required  for  a  portable  system  and  runtime  module  to  be 
developed.  Command  employment  could  not  be  entered  as  a  separate  entity  and  physically 
placed  in  the  evaluation  where  it  belongs.  Command  employment  is  placed  at  the  end  of 
duties  and  responsibilities  and  the  size  of  both  depend  on  their  placement.  Date  blocks 
could  have  their  format  better  controlled.  The  year  part  of  the  date  blocks  should  limit  the 
input  to  numbers  over  90  and  the  day  part  of  the  date  box  should  be  limited  to  numbers 
under  31. 
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Vin.  CONCLUSION 


A.  SUMMARY  OF  RESEARCH 

The  use  of  a  specific  design  methodology  or  design  tool  will  greatly  enhance  the 
user  interface  of  NTCSSAM’s  functional  development  as  well  as  the  documentation 
required  in  user  interface  design.  The  survey  forms  are  a  good  means  of  extracting  data 
from  users,  senior  management,  and  potential  users  but  great  care  must  be  used  in  the 
questions  that  are  generated.  Interviews  are  another  way  to  improve  the  design  of 
NTCSSAM  but  the  individuals  conducting  the  interviews  must  be  trained  and  experience 
at  this  task.  It  is  not  enough  to  be  an  expert  user  of  the  system  to  conduct  interviews.  The 
survey  form  in  this  research  produced  a  number  of  functionalities  from  users  but  did  not 
include  inputs  from  senior  officers  or  inspection  teams.  These  are  the  groups  that  create  the 
administrative  requirements  for  the  fleet  and  as  such  should  be  included  in  the  process  of 
design  of  NTCSSAM. 

The  Enlisted  Evaluation  Program  provides  an  example  of  an  evaluation  program 
that  can  be  included  in  NTCSSAM.  The  complexities  of  this  program  are  rooted  in  the 
interface  with  a  graphical  text  editor  and  printing  out  the  required  reports  in  a  specific 
format.  The  screens  give  a  good  example  of  how  to  present  the  data  and  the  thesis  text 
indicate  a  core  of  the  functionality  required. 

Using  Microsoft  Access  2.0  proved  to  be  a  good  tool  to  develop  a  rapid  prototype 
for  an  evaluation  function.  The  Enlisted  Evaluation  Program  was  designed  to  provide  the 
typical  user  with  a  more  efficient  way  of  creating  and  editing  evaluations  for  service  record 
entry.  Access  use  of  a  relational  database  made  the  manipulation  of  data  easier  while  the 
windows  based  presentation  created  a  intuitive  graphical  interface  for  the  user  to  create  and 
print  evaluations. 
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B.  RECOMMENDATIONS 

Before  the  current  design  method  is  followed  a  review  of  the  current  methodology 
should  be  conducted  and  compared  with  one  of  the  methodologies  listed  in  the  previous 
chapters.  NTCSSAM  is  designed  to  relieve  the  administrative  burden  of  fleet  personnel.  To 
best  provide  this  a  few  personnel  could  spend  a  few  weeks  doing  a  survey  of  shore  and  ship 
based  personnel  both  officers  and  enlisted.  Find  out  what  would  reduce  their  administrative 
burdens  or  rely  on  the  officers  interviewed  in  this  thesis  and  concentrate  on  training  and 
PQS.  The  requirements  or  functionality  for  any  administrative  program  should  not  be 
completed  without  a  detailed  review  of  the  documentation  that  requires  the  generation  of 
these  requirements  in  the  fleet.  Instructions  which  outline  these  requirements  are. 

•  OPNAVINST  3541 .  ID  (Shipboard  Damage  control  Readiness) 

•  OPNAVINST  354.4D  (Propulsion  Examining  Board  for  Conventionally 
Powered  Ships) 

•  COMNAVSUFLANT/PAC  3540. 1C  (Engineering  Department  Organization 
Manual) 

•  OPNAVINST  3 120.32D  (U.S.  Navy  Standard  Organization  and  Regulations 
Manual) 

C.  CONTINUED  RESEARCH 

There  are  many  possibilities  for  continued  research  and  developments  related  to 
this  thesis.  NAVMASSO  is  currently  converting  the  functionalities  of  SNAP  HI  and 
rewriting  them  in  ADA  to  be  incorporated  into  NTCSSAM.  These  functionalities  or  newer 
ones  could  be  converted  into  ADA  and  demonstrated  as  a  thesis. 

A  formal  design  method  could  be  implemented  to  create  NTCSSAM  and  a  set  of 
user  interface  screens  developed  using  a  rapid  prototyping  tool,  these  screens  could  be 
displayed  to  the  fleet  and  tested  using  a  formal  design  methodology. 

The  Enlisted  Evaluation  Program  could  be  expanded  in  several  was.  functionality 
could  be  added  to  it  incorporation  other  administrative  requirements  such  as  those  listed  in 
the  survey  form  for  NTCSSAM.  The  developers  kit  for  Access  could  be  used  to  convert  the 
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Enlisted  evaluation  program  and  any  other  functionalities  into  a  run  time  program.  If  a  run 
time  version  of  the  program  is  created  using  the  developers  kit  the  development 
environment  is  not  needed  to  run  the  program. 
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